Course: Android App Development
Topic: Understanding Synchronous and Asynchronous Operations
Course Link: Android App Development Course
Demo Link: Register for a Course Demo
Website: JustAcademy
Android applications perform many operations, such as displaying information, downloading images, requesting data from APIs, saving files, processing images, and reading information from a local database. The way these operations execute affects application performance, responsiveness, and user experience.
Synchronous operations execute in a sequence where the caller waits for an operation to finish before continuing. Asynchronous operations allow the caller to continue other work while an operation is in progress, receiving or processing the result when it becomes available.
Understanding these concepts is especially important in Android because the main thread is responsible for drawing the interface and processing user interactions. If long-running work blocks this thread, the application may freeze or display an Application Not Responding (ANR) dialog.
Kotlin coroutines provide a convenient way to write asynchronous Android code while keeping its structure readable and sequential.
A synchronous operation is performed as part of a sequential flow. The calling code waits for the operation to complete before proceeding to the next statement.
For example, suppose an application must calculate a total price before displaying it. The calculation completes first, and then the next statement displays the result.
fun calculateTotal(price: Int, quantity: Int): Int {
return price * quantity
}
fun main() {
println("Calculation started")
val total = calculateTotal(100, 3)
println("Total price: $total")
println("Calculation completed")
}Expected output:
Calculation started
Total price: 300
Calculation completedThe program calls calculateTotal() and waits for it to return before printing the total. This is a simple synchronous operation.
An asynchronous operation allows a program to initiate work and continue other tasks without waiting synchronously for the entire operation to finish. The result can be processed later through a callback, future, coroutine, observable stream, or another completion mechanism.
Consider an application downloading a list of products. While the request is running, the user should still be able to interact with the interface. Once the response arrives, the application can display the products.
fun main() {
println("Starting request")
// Imagine a non-blocking request is started here.
// The result will be handled when it becomes available.
println("The application can continue other work")
}This example illustrates the idea rather than performing a real asynchronous request. The next examples demonstrate actual asynchronous execution with Kotlin coroutines.
| Feature | Synchronous | Asynchronous |
|---|---|---|
| Execution flow | The caller waits for the current operation. | The caller can continue while work is pending. |
| Result handling | Often available directly after the function returns. | Handled when the operation completes. |
| Thread blocking | May block the calling thread. | Can avoid blocking while waiting. |
| UI responsiveness | Long blocking work on the main thread can freeze the UI. | Can keep the UI responsive when implemented correctly. |
| Code complexity | Often simpler for short operations. | Requires completion, error, and cancellation management. |
| Typical examples | Simple calculations and immediate value transformations. | Network requests, file I/O, and background tasks. |
| Result dependency | Later statements can use the returned result immediately. | Dependent work must wait for the result without blocking a thread unnecessarily. |
Important: Synchronous does not always mean slow, and asynchronous does not always mean fast. The correct approach depends on the operation, thread, and application requirements.
Blocking and non-blocking describe what happens to the calling thread while work is being performed or awaited. They are related to synchronous and asynchronous execution, but they are not exactly the same concepts.
A blocking operation prevents the calling thread from doing other work until the operation finishes. For example, calling Thread.sleep() blocks the current thread for the specified duration.
fun exampleBlockingOperation() {
println("Before waiting")
Thread.sleep(2000)
println("After waiting")
}This code blocks the thread for approximately two seconds. Avoid using Thread.sleep() or blocking I/O on the Android main thread.
A non-blocking operation allows the calling thread to continue working instead of waiting for completion. A coroutine can suspend while waiting for an asynchronous operation, allowing its underlying thread to perform other work.
import kotlinx.coroutines.delay
suspend fun exampleNonBlockingWait() {
println("Before waiting")
delay(2000)
println("After waiting")
}The delay() function suspends the coroutine without blocking its thread. It must be called from a coroutine or another suspend function.
The Android main thread, also called the UI thread, handles UI-related work such as processing user input, updating views, and coordinating screen drawing.
When an application starts, Android creates its main thread. If this thread spends too much time performing a blocking task, it cannot process other UI events promptly.
button.setOnClickListener {
Thread.sleep(5000)
textView.text = "Operation completed"
}This code is problematic because the click listener normally runs on the main thread. The five-second sleep prevents the application from processing other UI work during that period.
Operations that may take significant time should be designed so that they do not block the main thread. Examples include network requests, file reads, database queries, and expensive computations.
Kotlin coroutines make it possible to manage such work without manually creating a thread for every operation.
| Dispatcher | Purpose | Typical Use |
|---|---|---|
| Dispatchers.Main | Runs coroutine code on the main thread. | Updating Android UI state. |
| Dispatchers.IO | Designed for blocking I/O operations. | File operations and blocking network or database APIs. |
| Dispatchers.Default | Designed for CPU-intensive work. | Large calculations, sorting, or data processing. |
| Dispatchers.Unconfined | Starts in the caller's context until suspension, with more specialized resumption behavior. | Advanced cases; generally not the default choice for application work. |
For libraries that already provide main-safe suspend functions, such as many modern networking and database APIs, do not automatically wrap every call in Dispatchers.IO. Follow the library's documented threading behavior. Use dispatchers when the operation needs them.
Kotlin coroutines are a concurrency mechanism that lets developers write asynchronous code in a readable, sequential style. A coroutine can suspend its execution and resume later without necessarily blocking the thread on which it started.
Coroutines are especially useful in Android for network requests, database operations, and coordinating work across multiple application layers.
await().The suspend keyword marks a function that may suspend the current coroutine. It does not, by itself, guarantee that the function runs on a background thread.
import kotlinx.coroutines.delay
suspend fun fetchMessage(): String {
delay(1000)
return "Message loaded"
}The function waits asynchronously for one second using delay() and then returns a string. The coroutine can suspend without blocking the thread.
A suspend function must normally be called from another suspend function or from a coroutine builder, such as launch.
import kotlinx.coroutines.launch
import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
class MessageViewModel : ViewModel() {
fun loadMessage() {
viewModelScope.launch {
val message = fetchMessage()
println(message)
}
}
}In an Android application, viewModelScope is automatically cancelled when its ViewModel is cleared. The example prints the result; a real UI should expose observable state rather than relying on console output.
The launch coroutine builder starts a coroutine and returns a Job. It is useful when you want to start work without needing a direct result from the builder call.
import kotlinx.coroutines.delay
import kotlinx.coroutines.launch
import kotlinx.coroutines.runBlocking
fun main() = runBlocking {
println("Program started")
launch {
delay(1000)
println("Background task completed")
}
println("Main coroutine continues")
}The output will include the message from the main coroutine before the delayed task finishes. The outer runBlocking waits for its child coroutine to complete, making this example suitable for demonstration, not for blocking an Android UI thread.
The async coroutine builder starts a computation and returns a Deferred object. Calling await() retrieves the result, suspending the coroutine until the result is available.
import kotlinx.coroutines.async
import kotlinx.coroutines.delay
import kotlinx.coroutines.runBlocking
suspend fun getUserName(): String {
delay(1000)
return "Aarav"
}
suspend fun getUserScore(): Int {
delay(1000)
return 95
}
fun main() = runBlocking {
val nameTask = async { getUserName() }
val scoreTask = async { getUserScore() }
val name = nameTask.await()
val score = scoreTask.await()
println("Name: $name")
println("Score: $score")
}The two tasks can overlap because both are started before their results are awaited. The coroutine suspends as necessary without blocking its underlying thread.
| Feature | launch | async |
|---|---|---|
| Return value | Job | Deferred<T> |
| Main purpose | Start a task without a direct result. | Compute a value for later retrieval. |
| Result retrieval | Usually handled through state or side effects. | Use await() to obtain the value. |
| Common example | Load data and update a StateFlow. | Fetch two independent values concurrently. |
The withContext() function switches to a specified coroutine context for a block of work and suspends until that block completes. It returns the block's result.
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
suspend fun calculateLargeTotal(values: List<Int>): Long {
return withContext(Dispatchers.Default) {
values.sumOf { it.toLong() }
}
}This example moves a potentially expensive calculation to Dispatchers.Default. For a tiny list, the overhead may not be necessary; choose a dispatcher based on the actual workload.
launch starts a coroutine and returns a Job.async starts a coroutine and returns a Deferred result.withContext changes the coroutine context for a block and returns its result after the block completes.Android applications commonly request information from REST APIs. A network call should not block the UI thread. A Retrofit suspend function can be called from a coroutine.
data class Product(
val id: Int,
val title: String
)import retrofit2.http.GET
interface ProductApi {
@GET("products")
suspend fun getProducts(): List<Product>
}class ProductRepository(
private val api: ProductApi
) {
suspend fun loadProducts(): List<Product> {
return api.getProducts()
}
}import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
import kotlinx.coroutines.flow.MutableStateFlow
import kotlinx.coroutines.flow.asStateFlow
import kotlinx.coroutines.launch
class ProductViewModel(
private val repository: ProductRepository
) : ViewModel() {
private val _products =
MutableStateFlow<List<Product>>(emptyList())
val products = _products.asStateFlow()
fun loadProducts() {
viewModelScope.launch {
try {
_products.value = repository.loadProducts()
} catch (e: kotlinx.coroutines.CancellationException) {
throw e
} catch (e: Exception) {
// Publish an error state in a production implementation.
}
}
}
}This example demonstrates the execution flow. In production, use a dedicated UI state model that represents loading, success, and error states. Also configure Retrofit and provide the repository through a suitable dependency injection or ViewModel factory setup.
Asynchronous code can still be sequential. The important question is whether one operation must finish before another begins.
Use sequential calls when the second operation depends on the result of the first.
suspend fun loadOrderDetails() {
val order = api.getOrder()
val items = api.getOrderItems(order.id)
displayOrder(order, items)
}The items request needs the order ID, so the first request must complete before the second can begin.
Use concurrent execution when two operations are independent and can safely run at the same time.
import kotlinx.coroutines.async
import kotlinx.coroutines.coroutineScope
suspend fun loadDashboard() = coroutineScope {
val profileTask = async { api.getProfile() }
val notificationsTask = async { api.getNotifications() }
val profile = profileTask.await()
val notifications = notificationsTask.await()
DashboardData(profile, notifications)
}This example assumes the API service provides the indicated functions and that the required data classes exist. Both requests are started before their results are awaited.
Asynchronous operations may fail because of network problems, invalid input, server errors, parsing issues, or unexpected exceptions. Handle failures at an appropriate layer and expose a useful error state to the UI.
import kotlinx.coroutines.CancellationException
import kotlinx.coroutines.launch
import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
class ExampleViewModel : ViewModel() {
fun performTask() {
viewModelScope.launch {
try {
val result = fetchMessage()
// Publish success state.
} catch (e: CancellationException) {
throw e
} catch (e: Exception) {
// Publish an appropriate error state.
}
}
}
}Do not silently swallow every exception. Record appropriate diagnostic details securely, communicate failure to the user, and preserve coroutine cancellation by rethrowing CancellationException.
Android screens can be closed or recreated while a request is running. Lifecycle-aware scopes help prevent unnecessary work from continuing after the owning component is no longer active.
Cancellation is cooperative. Suspending functions such as delay() normally respond to cancellation, while CPU-intensive loops may need to check cancellation explicitly.
| Mistake | Problem | Better Approach |
|---|---|---|
| Running network calls on the main thread | The UI may freeze or trigger an ANR. | Use an asynchronous API and appropriate coroutine setup. |
| Using Thread.sleep() inside a coroutine | It blocks the underlying thread. | Use delay() for a coroutine-friendly wait. |
| Assuming suspend means background thread | A suspend function can still execute on the caller's dispatcher. | Use appropriate dispatchers when required. |
| Launching a coroutine in an unmanaged scope | Work may outlive the screen or component. | Use lifecycle-aware or otherwise well-defined scopes. |
| Using async when no result is needed | Can make the code less clear. | Prefer launch for tasks without a direct return value. |
| Ignoring exceptions | The application may fail silently or display stale data. | Expose success and failure states. |
| Starting dependent operations concurrently | Required data may not be available when needed. | Use sequential calls when operations depend on each other. |
| Updating views from an inappropriate thread | Can cause thread-related UI errors. | Perform UI updates on the main thread. |
Build a small Android application that loads product data from an API and displays it in a list.
viewModelScope.launch to initiate the request.After completing this project, you should understand how asynchronous work is started, how results are delivered to the UI, how failures are represented, and how lifecycle-aware coroutine scopes help manage work safely.
Answer: A synchronous operation requires the caller to wait for the operation to return before continuing its normal sequential execution.
Answer: An asynchronous operation allows the caller to continue other work while the operation is pending. Its result is processed when it becomes available.
Answer: Blocking prevents the calling thread from doing other work while waiting. Non-blocking execution allows the thread to continue, often by returning control or suspending a coroutine.
Answer: The main thread processes UI events and drawing. Long blocking operations can cause lag, frozen interactions, and potentially ANR errors.
Answer: A coroutine is a suspendable computation that can pause and resume without necessarily blocking the thread while it waits.
Answer: No. The suspend keyword allows a function to suspend. The coroutine's dispatcher determines its execution context, and the function may continue on the caller's dispatcher unless a context switch occurs.
Answer: launch returns a Job and is generally used for work without a direct result. async returns a Deferred value that can be retrieved using await().
Answer: Dispatchers.IO is designed for blocking input/output tasks, such as file operations and blocking network APIs.
Answer: When they are independent and do not require one another's results to start. Concurrent execution can reduce total waiting time.
Answer: Structured concurrency organizes related coroutines within defined scopes so their lifecycles, cancellation, and failure behavior can be managed predictably.
Answer: Thread.sleep() blocks the underlying thread. The coroutine-friendly delay() function suspends the coroutine without blocking its thread.
Answer: It associates coroutine work with a ViewModel lifecycle and automatically cancels that work when the ViewModel is cleared.
Synchronous and asynchronous operations are fundamental concepts in Android development. Synchronous code is often suitable for simple, short operations, while asynchronous techniques are essential for work that may take time, such as network requests, database access, and file processing.
By understanding blocking behavior, the Android main thread, Kotlin coroutines, dispatchers, and lifecycle-aware scopes, developers can create applications that remain responsive and handle background work reliably.
